\section{The Profiler Module}
One of the most crucial modules for the successful operation of our project, is the \emph{profiler}. Based on what are recommendations going to be generated? How will you know if other members of iSquirrel have the same interests as you? How can you be sure that a Wikipedia article is going to appeal to you? These and other questions can be easily answered (or implemented) once we have a profile for each user, that collects information about what they like.

We discovered that there are two main types of interests that should affect the recommendations of iSquirrel. We have the interests that the user specifically enters in the system, and we also have the interests that are implied from the articles the user likes. In the former case the user has a clear understanding that the subjects they enter into their profile will have a big impact on the recommendations they will get. In the latter case, however, it is not so obvious what happens in the background, once a user \emph{``likes"} a website, and how that affects the recommendations.

Therefore we decided to split the profile of the user to the \emph{Static Profile}, which contains the interests of the user as they were entered by the user, and the \emph{Dynamic Profile}, which contains information about the articles the user \emph{``liked"}.

\subsection{The Static profile}

\subsubsection{The problem}
This aspect of development brought a lot of issues to our attention which slowed
 down the progress of the second iteration. One of these issues involved the way
 the user would enter their interests into the system. This surfaced as a problem when we realised that what humans conceive as an interest might not have a respective semantic ontology, that we could use to query DBpedia. Even worse, the way we use to describe an interest would definitely be different from the semantic signature  of the interest. Would we have to create a mapping between the human readable interest and the semantic one? And how many possible interests are there? 

\subsubsection{Possible solutions}
One solution was to limit the user's input to predefined keywords. Each keyword would then get associated with up to five semantic ontologies that we could later use to generate recommendations. However, this solution would require too much time wasted on mapping interests to ontologies, and also time wasted on compiling a list of all the ontologies we could use. The other problem was that the user wouldn't have the flexibility of choosing their own interest, no matter what it is - it would have to be from the given list. 

Another idea was to have a compiled list with all the possible semantic ontologies. The user wouldn't have to choose from a list of interests, but instead they would just write their interest, and we would then do a string-lookup in that list, with the interest as a keyword. The matched ontologies would then be stored under the \emph{Static Profile} of the user. This approach again limits the user considerably on what they can type. Another issue is that many interests would normally relate to ontologies that are written in a completely different way - for example if you are interested in ``travelling" the ontology ``Place" is something you would be interested in. 

\subsubsection{Wikipedia to the rescue}  
We finally decided that having a pre-compiled list of ontologies would be a bad idea, and that the users should have the freedom of entering whatever they like as their interests. We made a potentially safe assumption that a Wikipedia article is going to exist for every possible interest. Therefore a respective page would appear in DBpedia, with information about that article. When a user enters an interest, we modify the case of the letters if needed and replace spaces with underscores and we get a page in DBpedia. We extract the information we need from that page: namely its \emph{subject}. We then query DBpedia and receive all subjects, that are one level more specific than the one(s) we found previously. We then store all these subjects in our database, and inform the user that their interest was added successfully. In the case that the input from the user did not bring any results, the user is prompt to try again. 

\subsubsection{Other issues}
This approach has proven to be the most effective and reliable. However there were some issues with it that we had to fix. Firstly, not all articles in Wikipedia can be found under the name we expect them to be. For example there is no article with the name ``Beethoven" - instead it is called ``Ludwig van Beethoven". Fortunately for us, there is an entry in DBpedia with the former name that specifies that it is a redirect to the latter one. All redirections are described in a similar way. In our case, before trying to retrieve the subject(s) of a page, we first check if that page redirects to another one. In that case we start again using the new page as our target.

Another issue we had was that sometimes, when a user entered an interest, what iSquirrel understood was not what was originally intended from the user. This problem emerged when we tried our system with the interest ``Clubbing". The user entered this interest, but instead of getting results related to clubbing they were getting article recommendations about diseases! It turned out that clubbing is a deformity of the fingers and fingernails that is associated with a number of diseases. Hence all those recommendations about diseases. 

The solution to the problem above was simple. Since we can't know what the users mean when they type something as an interest, we can at least inform them about what we understand. As illustrated in Figure \ref{user_interests}, when an interest is added it comes with a short description about it. This is done by receiving the \emph{abstract} of the article that corresponds to the interest, using DBpedia. 

\subsubsection{Example}
As an example consider a user who enters ``Programming" as their interest. Using DBpedia we find out ``programming" is a redirect for ``computer programming", so we start again using the second term this time. We find the relevant page and read its subject(s): ``Computer programming". We then try to receive all subjects that are one lever more specific. In this case there are around 20, including ``Programming languages", ``Algorithms", ``Debugging", ``Refactoring" etc.

If the user was more specific and entered an interest such as ``Alan Turing", the first level subjects  would include ``Alan Turing", ``British cryptographers", ``Suicides by poison", ``History of artificial intelligence" etc. This shows that the \emph{Static Profile} of the user can be kept relevant to the user's interests, no matter how specific or general one is at the time they enter their interests.
\footnote{\emph{Subject} names are simplified to accommodate more readability for the reader. }

% H denotes HERE
\begin{figure}[H] 
\begin{center}
\includegraphics[width=4in]{resources/interests.png}
\caption{ Interests entered by a user }
\label{user_interests}
\end{center}
\end{figure}


\subsection{The Dynamic profile}
\label{sec:dyn-profile}
While the \emph{Static Profile} is obvious to the user, the \emph{Dynamic Profile} is implicit. The user is not aware of it and they have no control over it. It is used by the Dynamic Recommender when we want to generate recommendations based on the pages that a user has liked and thus provide a more personalized experience.

\subsubsection{A Property}

A \emph{property} is a piece of information about a page. It has a type (or attribute) and a value.  A property might appear multiple times, in different articles, therefore a 'frequency' field is also needed. The 'id' is there for database purposes. DBpedia keeps a list of all kinds of properties for all pages.  When a user \emph{``likes"} an article - page, it means that all the properties returned from DBpedia about that page should be relevant to the user. Listing~\ref{lst:property} shows how we represent DBPedia properties as objects.

\lstset{language=Java}
\lstset{backgroundcolor=\color{white}}
%\lstset{numbers=left, numberstyle=\tiny, stepnumber=1, numbersep=5pt}
\lstset{keywordstyle=\color{red}\bfseries}
\begin{lstlisting}[frame=tb, caption=Property class, label=lst:property]
public class Property {
	Long id;
	private String value;
	private String attribute;
	private int frequency;
	...
}
\end{lstlisting}

An example of a property is the one that describes the type of the game chess. The type (or attribute) of this property is ``rdf:type" and the value of it is ``opencyc:en/BoardGame", as returned from DBpedia. But how is that useful to us? 

\subsubsection{The profile}
Whenever a user \emph{``likes"} a page, we can retrieve from DBpedia all the properties of that page\footnote[1]{We sometimes refer to these properties as \emph{page information}.}. We store these properties in our database. For those that were already there, we simply increase their frequency, otherwise we just set it to one. Each user has their own list of properties, and that is what consists the \emph{Dynamic Profile} of the user.

Initially the \emph{Dynamic profile} of a user is empty. Once the user starts ``liking" pages, this profile gets bigger and bigger. For simplicity we write to the database the properties the way we receive them - no shortcuts are involved. It is important noting that the way we chose to write properties in this profile, makes the process completely transparent to us, as we never try to parse them when generating recommendations. They could have any format; we don't care as we never try to understand that format in our code. This simplifies matters a lot, as the diversity and range of properties we receive is enormous and trying to parse them would be a very complex process.

\subsubsection{Blacklist}
A page has lots of information associated with it in DBpedia. Lots of them are not necessary for the purposes of our project. Apart from not being necessary they can also affect the dynamic recommendations in a negative way.  After careful analysis of the properties we were receiving for each query, we constructed a set of unwanted properties, namely the blacklist. We then used the blacklist to filter the properties against it, so information with no benefit for the profile is not stored in the database. There is, for example, a property called ``wikiPageUsesTemplate" which provides no relevant information about the article it came from.

\subsubsection{Importance of the \emph{Dynamic Profile}}
The \emph{Dynamic Profile} is what allows our system to be adept and astute. The more we know about what a user likes, the better and more targeted recommendations we can provide. One important aspect of this profile is its breadth of information. The scope of the information we store when a user \emph{``likes"} an article is very wide, and it represents the knowledge that our system obtains about the user. This knowledge is what makes our project more scalable and extensible, as we can use it to introduce even more modules. They might not have to do with recommendations, but if we need something that relies on the personality of the user, then we are halfway there (under a semantic context that is) as we have the knowledge ready to use. 


\subsubsection{Random keywords}
Another benefit that \emph{Dynamic Profile} brings to our system is the ability to have random keywords that describe interests of our users. These keywords can be used when searching YouTube for videos that could be of interest to the user. Random keywords are produced by selecting the most frequent properties that appear in the \emph{Dynamic Profile} of a user, and then randomly selecting the value of one of them. This value enacts something that the user has a genuine interest in, as it came from pages that they have liked and it was also frequent.

\subsection{Further improvements}
\emph{Static Profile} and \emph{Dynamic Profile} are performing well they way they are now. However, we could improve the performance of our database (by reducing wasted space) by minimizing the strings that are used to describe properties. Right now the type of a property is a long address, of which only the last bit is of importance to us. Therefore we could save ourselves from wasting space by writing only the part of that address that is needed.

Another thing that we could improve is how we present the description we receive about an interest. Consider for example the description for ``Theatre" in Figure \ref{user_interests}. It mentions ``see spelling differences", something which provides no useful information to the user. We could simply scan the returned description and remove occurrences of phrases like that.

